The aim of autonomic networking is to achieve self-configuring nodes which can adapt to different environments and minimise human intervention throughout their lifecycle. Conventionally, when a human configures a router or other piece of infrastructure, s/he will always adapt to the environment into which the kit is being placed.
Thus different pieces of equipment implicitly play different roles in an infrastructure—even if they are physically or virtually identical—just because they are configured differently by network engineers. These hand-crafted configurations are complex and can be error-prone. This means changes, improvements and fixes can be complicated and slow to test and roll out.
It is for this reason, in part, that the devops movement which prescribes software-defined configuration for service automation is gaining momentum. For example, the configuration of compute nodes may be specified by configuration management tools such as Ansible, or Puppet, through models. The decision to change the configuration of these nodes may be made by an operator, or autonomically according to some (node or system-wide) closed-loop control effecting a sense, plan, act cycle.
Today's approach to device configuration undermines three key features of a successful business:                1. Agility                    Killed because human intervention is slow and too late.                        2. Optimisation                    Limited by the skill of individual humans acting on retrospective analytics.                        3. Compliance                    Security and audit holes abound in manually-produced configurations, imperfectly applied.                        
Autonomic networking seeks to mitigate this problem by allowing individual devices to self-configure as part of an autonomic domain, and minimise human intervention throughout their lifecycle.
A key part of autonomic networking is the process by which a newly installed piece of equipment advertises its presence, and receives authorisation to communicate, via a proxy, with a registrar such that it can enroll in the registrar's configuration domain.
This much has been designed already.
But let us consider this process—where each device plays a part by receiving and transmitting data. The process may depend on various factors such as what the device capabilities are, whether it was the first to be switched on, and so on.
There are two means by which this process can be made to happen:
The first, here termed “Orchestration”, is when a sequence of events is driven through a single point of control—for example, a device running a program written for the purpose of controlling the others. The term orchestration is most commonly used when talking about standing up environments such as Linux containers, SQL databases and so forth, ready to run some application or other. Most of today's orchestration is hand-crafted coding. But higher-level orchestration tools exist for various specific application areas, such as BPEL, APIC-EM, Chef, Puppet and Juju. They allow us to define policies of one kind or another, perhaps including flowcharts, and they handle the detail for us.
The second approach, here termed “Choreography”, is where there is no central point of control driving the sequence of events. Each device does its own thing, including collaborating with others, without a central controlling program. Choreographies are common throughout the internet. One degenerate case is when a client makes a request on a server and gets a reply. But suppose that server, in turn, makes requests on other servers before delivering its reply? Then the choreography is more complex. No single point of control exists for the global pattern of events in this case.
Effective autonomic networking requires that the model of device behaviour supports both orchestration and choreographic processes effectively. By behaviour, we mean the pattern of events that occur in respect of a given device. It should be noted that effective support for both orchestration and choreography is significant not only for autonomic networking, but also for other processes that require some measure of self-organisation in a network environment.